feat(token-fundraiser): add pinocchio example - #708

Ports the token-fundraiser example to Pinocchio (the anchor example has no
native sibling). A maker starts a fundraiser with a token target and a
duration; contributors deposit tokens into a PDA-owned vault up to a
per-contributor cap while the fundraiser runs. Once the target is met the
maker releases the funds; if the fundraiser ends without meeting the target,
contributors can refund their deposits.

Four instructions (initialize, contribute, check_contributions, refund) over
two PDA state accounts, using pinocchio-token / pinocchio-associated-token-
account for the vault and transfers, PDA-signed CPIs to move funds out of the
vault, and the Clock sysvar for the time-based logic. The two inverted time
checks in the anchor example are corrected here (contributions are only
accepted while running; refunds only after the fundraiser ends).

The litesvm test drives the full lifecycle: the refund path (contribute, warp
the clock past the deadline, refund) and the release path (ten contributors
reach the target, then the maker releases the funds), controlling the clock to
exercise the time branches.

…ded totals

contribute skipped the contributor PDA derivation whenever the supplied
record was already program-owned, so a signer could credit their transfer
to another participant's record: it bypassed the per-contributor cap and
left the tokens claimable by that record's owner through refund. The
derivation now runs before the branch, for existing and new records alike.

check_contributions and refund gated on the vault's token balance. The
vault is a standard ATA, so any holder could transfer straight into it and
push that balance past the target, releasing the fundraiser and blocking
legitimate refunds without any recorded contribution. Both now read
current_amount; the release still drains the full vault balance.

Adds LiteSVM coverage for both: a contribution into a substituted record is
rejected, and a direct vault transfer neither releases the fundraiser nor
prevents a refund. Both tests fail against the previous program.

contribute took the contributor bump from instruction data and fed it to
create_program_address. Several bumps can yield a valid address for the same
seeds, so a contributor could open extra, non-canonical records for
themselves and be metered against the per-contributor cap separately on each.
Those records were also unrefundable, since refund only ever derives the
canonical address.

The bump is now derived on-chain with find_program_address and the supplied
byte is gone from the instruction data entirely, so there is no longer a
caller-controlled input to the derivation. This matches the Anchor version,
whose `seeds = [...], bump` constraint likewise derives canonically rather
than accepting a bump from the client.

Adds a test that a contributor_account which is not the canonical PDA is
refused before any record is created.